test: add an example of how to invoke Rspack#2846
Open
acozzette wants to merge 14 commits into
Open
Conversation
|
nickschaap
reviewed
May 15, 2026
|
|
||
| module.exports = defineConfig({ | ||
| entry: { | ||
| main: './rspack_entry.js', |
Contributor
There was a problem hiding this comment.
So is rspack resolving this from the current working directory or relative to the config file since the config file will live in a separate bazel-out tree than than this entrypoint
Contributor
Author
There was a problem hiding this comment.
I believe it's resolving it from the current working directory. js_run_binary's working directory is basically "bazel-out/<target platform>/bin/" + chdir where in this case chdir is "rspack".
For the output path below, I did have to replace __dirname with process.cwd() to reflect that the config file is no longer placed in the target platform bin directory.
This example started out as a test case by @jbedard and @nickschaap showing how `js_run_binary` can sometimes fail to work correctly when the execution and target platforms are different. I was able to get it working, primarily by setting `use_execroot_entry_point = False`. The problem with the default behavior (`use_execroot_entry_point = True`) is that it runs target-platform sources during the build action, which can go haywire if the target platform is meaningfully different from the execution platform. Getting all the sources in the right place and built for the right platform is not entirely straightforward, so I thought it would be good to have a simple example showing this. I added a lot of comments trying to explain why everything is set up the way it is.
…tform separation For webpack and rollup invocations, configs and their npm plugin/loader dependencies now live in the tool binary's runfiles rather than being passed as target-platform action inputs. This ensures all exec-platform code runs from the same runfiles tree, avoiding resolution failures in cross-platform builds. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
…orm separation Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
…orm separation Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
…/target platform separation Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Contributor
Author
|
I went ahead and updated a bunch of other examples in the repo to use this same pattern. Luckily it was easy to just point Claude at the original example and ask it to imitate that. |
Member
|
I think we need to find a way to still directly invoke Wrapping things like tool config files+deps into |
Contributor
Author
|
I tweaked things so that now we are down to just one |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This example started out as a test case by @jbedard and @nickschaap showing how
js_run_binarycan sometimes fail to work correctly when the execution and target platforms are different.I was able to get it working, primarily by setting
use_execroot_entry_point = False. The problem with the default behavior (use_execroot_entry_point = True) is that it runs target-platform sources during the build action, which can go haywire if the target platform is meaningfully different from the execution platform.Getting all the sources in the right place and built for the right platform is not entirely straightforward, so I thought it would be good to have a simple example showing this. I added a lot of comments trying to explain why everything is set up the way it is.
Changes are visible to end-users: no
Test plan